home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
ietf
/
osix400
/
osix400-minutes-89nov.txt
< prev
next >
Wrap
Text File
|
1993-02-17
|
15KB
|
350 lines
CURRENT_MEETING_REPORT_
Reported by Robert Hagens/Univeristy of Wisconsin
AGENDA
o Announcement of new name
o Status of the quest for "NREN"
o Review of Scope
- 822 <-> X.400 gateway issues (RFC 987 and successors)
- X.400 operational issues in a dual protocol internet
o Review of Issues
- 822 <-> X.400 Gateways
* RFC 987 gateway background
* Table Maintenance
* Locating a Gateway
* ORAddress Structure
- X.400 Operation
* Routing to destination or 822 gateway
* Use of Internet Technology
* Mixed Stacks
* MTA names
* Use of "NREN"
Presentation of a new, unified address structure
ooEnumerating and discussion of major tasks
MINUTES
The meeting was convened by chairman Rob Hagens. An attendance list
will be published with the Proceedings of the IETF. The Domain Name WG
meet jointly with the OSI-X400 WG during the afternoon.
WORKING GROUP SCOPE
The scope of the WG was presented:
o RFC 822 <-> X.400 Gateway Issues
- maintenance of RFC 987 mapping tables
- routing toward a gateway
o X.400 Operational Issues
- Structure of OR-Addresses in the Internet
- X.400 Routing
- Nameservers
The group determined that (with the exception of determining the
structure of OR-Addresses in the Internet), they should not try to solve
"pure-OSI" problems. These problems fall into the domain of other OSI
groups. The WG should develop and maintain a close relationship with
such groups:
o NIST X.400 SIG
o NIST X.500 SIG
o GOSIP X.400 committee
PRESENTATION OF ISSUES
Rob Hagens presented a list of issues facing the WG. That list is
included here:
Issues, Problems, and Proposed Solutions to
X.400 and 987 Gatewaying in the Internet
1. X.400-RFC 822 Gateway Issues
(a) Background
This background information serves as a very brief tutorial on
RFC 987. The information presented below is far from complete.
It is strongly recom- mended that anyone interested in the
issues dis- cussed below should obtain and read RFC 987.
RFC 987 specifies how messages should be gatewayed between RFC
822 based systems and X.400 (1984) based systems. Although the
RFC describes the translation of various protocol elements from
one system to the other, the following discussion is limited
only to the translation of addresses.
RFC 987 specifies that translation from one address space to
another may occur in 2 ways. The normal method of translation
(table lookup) is used when sub-trees of the different name
spaces are associ- ated via mapping tables. The fall back
method of translation (encoding in the other address space's
format) is used when table lookup fails.
Table lookup is accomplished through the use of 2 separate
tables: an RFC 822 -> X.400 table, and an X.400 -> RFC 822
table. Each entry in the tables is indexed by a key. The
address to be mapped is compared against each key in the table.
The com- parison that matches the most components is selected
(i.e., the "longest" match). The value associated with the key
is a template that is used to construct the translated address.
i. Table Driven Mapping
For example, the 822 domain "merit.edu" could be associated
with the OR Address space "C=US, PRMD=NREN, O=MERIT.EDU" in
a mapping table. Thus, when translating the 822 address
"hwb@merit.edu", the domain specification "merit.edu" would
be compared against the various keys in the table. Assuming
that the table con- tains two keys "edu" and "merit.edu",
the longest match "merit.edu" would be selected. The
template associated with the key "C=US, PRMD=NREN,
O=MERIT.EDU", would be used to produce the address "C=US,
PRMD=NREN, O=MERIT.EDU, OU=CS, PN=HWB". In this example,
the translation of the last domain component "cs" is
performed systemat- ically. The translation of the
right-hand side of the 822 address "hwb" is specified by RFC
987.
This example shows that a single entry can specify the
translation for all addresses in the "merit.edu" domain.
This entry associates the 822 domain "merit.edu" with the
X.400 namespace under "C=US, PRMD=NREN, O=MERIT.EDU".
An analogous scheme is used for the opposite direction.
ii. Mapping Without Tables
If a mapping table entry is not present, transla- tion may
still occur. However, in this case, the translation is less
sophisticated. Translation, in this case amounts to
encoding the address in the other system's format. RFC 987
specifies default rules that may be used to perform this
encoding. These rules specify the manner in which an RFC
822 address may be encoded in X.400, and vice versa. The
following examples consider each direction separately:
iii.RFC 822->X.400
In this direction, the domain-defined attribute "RFC-822"
may be used to encode an RFC 822 address. For example, if
an 822 address "hagens@janeb.cs.wisc.edu" was translated by
a gateway that had an X.400 address "C=US, PRMD=NREN,
O=MERIT.EDU", then that gateway (in the absence of a mapping
table entry) would produce the address 'C=US, PRMD=NREN,
O=MERIT.EDU, DD.RFC- 822="hagens@janeb.cs.wisc.edu"'.
iv. X.400->RFC 822
In this direction, left-hand side encoding may be used to
encode an X.400 address within 822. For example, the X.400
address "C=FR, ADMD=FRENCH-PTT, O=INRIA, PN=HUITEMA", when
considered by a gateway with the 822 address "merit.edu",
would be translated to '"C=FR, ADMD=FRENCH-PTT, O=INRIA,
PN=HUITEMA"@merit.edu'.
(b) Issues
i. Table Maintenance
The mapping table entries must be kept consistent among all
the 987 gateways in the world. This is very difficult to
accomplish by hand. How can the table maintenance task be
automated?
ii. Finding the Gateway
How does a mail router find a 987 gateway? In the
X.400->RFC 822 direction, it is the responsi- bility of
X.400 routing. Note: X.400 routing is not defined by any
standard. In the RFC 822- >X.400 direction, it is the
responsibility of 822 routing. Conventional MX records
could be util- ized to solve the problem.
iii.Structure of X.400 addresses
It is desirable to provide a default X.400 address for hosts
within the Internet. This address will be structured so
that the X.400 address space corresponds with the domain
namespace. What is the best structure to use for this
purpose?
The choice of format of X.400 addresses, and the
corresponence of these addresses to 822 domains will
determine the contents of the of 987 mapping table entries.
oProposed Solution
The currently proposed solution is to map the top and
second level domains to the ORAddress "organization"
attribute. Subsequent lower level domains will be
mapped to a sequence of "organization unit" attributes.
For example, "venera.isi.edu" would map to "O=isi.edu,
OU=venera".
oUse of 'NREN' as a PRMD name
The intended use of "NREN" as a PRMD name is to identify
a management domain within which every registered
Internet entity has a default X.400 Address. This
address would be based upon the Internet domain name.
We expect some or all currently registered entities to
decide for themselves whether they wish to use the
default or register another name in another way. This
default provides a useful and helpful option without
constraining any individual entity to keep what the
default provides for them.
Is it necessary to define a second PRMD name which would
identify a management domain within the NREN that
utilizes X.400 addresses that are not based upon
Internet domain names? If this is true, is the original
use of "NREN" incorrect?
We need to show "ownership" of the name "NREN" so that
other groups do not have the right to register it.
Trademarking is the first step. Other uses of "NREN"
should be looked into. Any way that we can show "use"
of the name will help establish our "ownership".
2. X.500 Operation Issues
(a) Issues
i. Distinguished Names
Who will determine the structure of X.500 dis- tinguished
names (and the objects they locate) for use within the
Internet community?
ii. DNS coexistence
How should the DNS and X.500 coexist?
iii.Domain Distinguished Names
Is it acceptable, for transition purposes only, to suggest
that Domain names be used as Dis- tinguished names?
DISCUSSION OF ISSUES
Non-USA Internet Sites
The default OR Address may not be acceptable for Internet sites that are
not within the USA. 1) The WG cannot mandate the format of addresses
within a foreign country. 2) the NREN is a national object. Are these
reasons sufficient to prevent the definition of a default name using
NREN? At least, it should be made clear that the default name is valid
for USA-Internet sites only. This may not be inappropriate if many
foreign countries have already defined the X.400 registration policy
that would affect the foreign Internet sites.
"NREN"
The name "NREN" was originally choosen to be a PRMD name. The purpose
of this PRMD was to contain OR Addresses based upon Domain Names. It
was suggested that perhaps "NREN" is not appropriate for this use. No
other name was decided upon. Possible candidates are names that convey
some concept of Domain Names, such as "DN". This change would allow the
name "NREN" to be used by a FRICC-run PRMD.
Another option for a PRMD name would be to use the numeric form.
The effort to pre-register "NREN" as an ANSI OSI Organization name
failed. It is not clear that the OSI X.400 WG should attempt to
register the name until its exact use has been determined.
It was suggested that the WG should consider producing a specification
for written OR Addresses.
PRESENTATION OF A NEW, UNIFIED ADDRESS FORMAT
Paul Mockapetris presented his ideas regarding a new style of address.
He would like to see the world move forward with the development of a
unified, simple address structure. His proposal is a format that has
RFC 822 compatible syntax, whose semantic value is that of an X.500
distinguished name. These new addresses would be very short and
user-friendly. The new addresses could be used to look up both X.400
ORAddresses as well as conventional 822 addresses. The look up
mechanism could utilize the DNS as well as X.500.
GATEWAY SCENERIOS
A discussion of RFC 822 - X.400 gateway (987) scenarios produced the
following questions:
o Will any 987 gateway provide connectivity to every X.400 MTA?
The answer to this question will determine whether an 822 transfer
agent must choose a specific 987 gateway based upon the destination
address, or if the closest, default 987 gateway will always
suffice.
o Is there really benefit to table driven mappings or is it
sufficient to simply use default encodings?
A scheme that utilizes the DNS to aid a 987 gateway was discussed. The
scheme requires the following components:
o An ASCII (canonical) representation of ORAddresses.
o A new tree of the DNS that is based upon canonical ORAddresses
strings (called ORADDR). This tree is populated with MX records
(that store the SMTP 822 address of 987 gateways), and TO-SMTP RRs.
o Two new DNS resource records. TO-SMTP RRs are stored in the ORADDR
tree. They contain the information necessary to translate an X.400
address into an 822 address. TO-X400 RRs are stored in the
existing DN tree. They contain information necessary to translate
SMTP 822 addresses into X.400 addresses. A distributed collection
of TO-SMTP and TO-X400 records correspond to the 987 mapping tables
X.400 to RFC 822 (mapping 1) and RFC 822 to X.400 (mapping 2),
respectively.
A sample scenario would be:
822->X.400
Case A The destination address is an SMTP address which has been
previously associated with an ORAddress. This means that
there is a TO-X400 RR that describes how to translate the SMTP
822 address into an ORAddress. The originating transfer agent
will look up the destination address and receive an MX record
and a TO-X400 RR. The MX record identifies a 987 gateway and
is used to transfer the message to that gateway. The TO-X400
record is ignored by the originator.
When the 987 gateway receives the message, it will lookup the
destination address and receive an MX and TO-X400 RR. The MX
record is ignored, but the TO-X400 RR is used to translate the
destination address into an ORAddress.
Case B The destination address is an ORAddress. The originating
transfer agent will look up the destination ORAddress in the
ORADDR tree and receive an MX record. The MX record
identifies a 987 gateway and is used to transfer the message
to that gateway. The destination address sent in the SMTP
envelope will contain "ORAddress"@gateway.
X.400->822
Routing to the 987 gateway is not within the scope of the WG; it is
assumed that the message has already reached the 987 gateway.
Case A The destination address is an ORAddress which has been
previously associated with an SMTP 822 address (sub)tree.
This means that there is a TO-SMTP RR that describes how to
translate the ORAddress into an SMTP 822 address.
When the 987 gateway receives the message, it will lookup the
destination address in the ORADDR tree and receive a TO-SMTP
RR. The TO-SMTP RR is used to translate the destination
address into an SMTP 822 address.
Case B The destination address is an 822 address which has been
encoded in an ORAddress.
When the 987 gateway receives the message, it will translate
the destination address into an 822 address using the default
encoding rules.